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Preface 


Author’s Note 


This document is a basic training tool that covers various aspects of a systems 
analyst’s job. It emphasizes, as the title states, “Basic Systems Analysis and 
Design Techniques’. There are, of course, many other areas of responsibility. 
This manual, however, should give the inexperienced analyst a start in the 
right direction. 


A number of topics are addressed, mostly from the “what to do” and “how to 
do it” point of view. The section “Major Events in Designing and Implement- 
ing a System” should provide an overall perspective of the things an analyst 
has to do, and a sequence in which they should be performed. Knowing 
these, a newcomer to systems analysis should have an idea as to where to 
begin, and the questions to ask. 


Too frequently a person with no systems background or training 1s made a 
systems analyst and is perplexed as to where to start and what to do. This 
manual is intended to assist the applications analyst in learning the basics of 
analysis and design, and will also help the beginning analyst to decide how to 
proceed into the “what’s, how’s, and why’s” involved in such things as test 
plans, documents of understanding, testing, tracking mechanisms (PERT, 


Gantt charts), etc. 


Most of the ideas in this manual are the result of personal experience in 
designing and installing systems for IBM customers and internally for the IBM 
Corporation. Every effort has been made to see that the proper credit has 
been given to any material knowingly borrowed from others. In other in- 
stances, however, the origin of the material is not known as it was taken from 
notes made while attending classes over the years or from information re- 
ceived from others. 
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Introduction 


In the full scope of designing and implementing a system, the traditional 
systems analyst or engineer takes complete responsibility for the project. In 
some environments, however, the job is broken down into various areas of 
responsibility — the applications (or user) systems analyst, the programmer- 
analyst, programmer, and the operational analyst. 


This publication is oriented to the newcomer systems analyst in a user envi- 
ronment, and its objective is to give some practical ideas, tools, and principles 
with which a system can be analyzed, designed, and installed. It is intended 
to be practical, not theoretical. 


Virtually every idea presented herein 1s used by analysts to good advantage. 
To obtain a more complete understanding of the meaning, use, and impact of 
the material presented, a reader should try to visualize an analyst creating an 
entirely new system for an area in which the analyst has no background or 
experience. Knowledge gained from system or program maintenance, or of a 
particular system known intimately, should not be allowed to interfere with 
this visualization. The reader should keep in mind that this manual uses the 
following guideline: a system should be designed to meet the needs of the 
business, and oriented to and for the people that are going to use it. People 
should run the system and the ultimate requirement for a successful system is 
its orientation to the needs of the end users. 


Definitions 


Definition of User 


Definition of System 


To ensure a clear and consistent understanding of what a system really is and 
what is meant by systems analysis, the following definitions are provided. 


The term “user” as used in this manual does not refer to members of a 
facility’s data processing staff. Instead, the users are expected to be the 
individuals who actually use the system to carry out their job responsibilities: 
the foremen or other shop floor workers who use terminals to advise the 
system that a job has been completed, and request a new job assignment; or 
the production manager who also uses a terminal to determine the scheduled 
load on a specific machine group. Or the users may be clerks in the accounts 
receivable department who use terminals to determine the specific invoice 
against which a cash receipt should be credited; or the company controller 
who asks for information concerning the company’s cash commitments as 
opposed to anticipated cash receipts for the next six weeks; or the company 
president may use a terminal to obtain data concerning the profitability of 
various product lines. Or the users may be individuals who receive printed 
reports concerning parts shortages, anticipated receipts, or planned produc- 
tion, for example. 


It is recognized that data processing groups also have their own internal 
systems, procedures, controls, reports, etc., and, therefore, can also be system 
users. However, in the interest of simplicity, the term user as used herein 
refers to non-data processing personnel. 


Some dictionary definitions for the word system include: ‘“‘a regularly inter- 
acting or interdependent group of items forming a unified whole’, “a group 
of devices or artificial objects or an organization forming a network, especial- 
ly for distributing something or serving a common purpose’’, “an organized 
set of doctrines, ideas, or principles usually intended to explain the arrange- 


ment or working of a systematic whole”, “‘a coordinated body of methods ora 
complex scheme or plan of procedure”. 


All of the above definitions apply to system as it is used herein. Further, in 
this publication, system also encompasses the forms; displays and reports; 
files; telecommunications; instruction manuals and user guides; maintenance 
activity; edit and audit procedures, routines, and messages; and all the other . 
interrelated elements that must be defined, designed, and/or programmed to 
produce the desired system objectives. 


Definition of Systems Analysis 


Systems analysis can be defined as the analyzing and subsequent organizing 
of a problem to make it suitable for solution or processing by computers and 
other data processing equipment. This includes the organizing of a system of 
interrelated data processing equipment to perform a given function or pattern 
of functions. More specifically, systems analysis is the analysis of an activity 
to determine precisely what must be accomplished and how to accomplish it. 


Definition of a Systems Analyst 


A systems analyst is that person who performs the study or who does the 
“Systems Analysis”. More specifically, a systems analyst with respect to data 
processing (DP) has been defined as an individual who “works with people 
associated with DP systems to resolve problems and to aid in the develop- 
ment, monitoring, control, and change of a DP system”. 


A good systems analyst is much like a good cultural anthropologist: to do a 
good job, the anthropologist has to live with the natives, learn their ways, 
study them, and yet not become so identified with them that perspective is 
lost — in short: “Be in their world, but not of it.” 


And so it is with a good systems analyst: if possible, an analyst must learn an 
area even better than the people working in it. But at least from the technical 
or systems viewpoint, the analyst must always keep in mind the basic 
objectives: 


Determine what is really needed to improve the operation. 


Determine what is the best way of fulfilling the needs on a reasonable cost 
basis, and in an appropriate time frame. 


The analyst is a business problem solver and the job, as will be seen later, is 
varied, complex, and significant. 


Major Events in Designing and Implementing a System 


Before dealing specifically with techniques, it may be desirable to review the 
general steps or major events in the design and implementation of a system. 
They are: 

e Determination of needs and objectives 

¢ Development of justification for them 

e Presentation to management 

e Approval to proceed 

e Effort sizing. Analysts, programmers, and users 

¢ Commitment to proceed 

¢ Development of general design specifications 

e General design acceptance 

e Preparation of equipment order 

e Preparation of forms order 

e Development of detail design specifications 

e Detail design acceptance 

e Ordering equipment, forms, software, cabling, telephone lines, etc. 

e Publishing document of understanding (D.0.U.) 

e Approvals of D.O.U. 

¢ Test plan 

e Program design 

e Program coding 

e Installation of equipment/software 

e Testing. Program (unit), systems/integration, user acceptance 

e Education 

e File cleanup 

e File initialization 


e Pilot run 


Establish a Foundation 


Determine Needs and Objectives 


e Parallel runs 
e Formal installation and cutover 
e Maintenance/tracking and followup 


Essentially, the systems analyst is involved with every event except, perhaps, 
program design or coding. The importance of the analyst in the total picture 
of a new system — a number of major events, in each of which the analyst 
plays a major role, and many of which require totally different approaches 
and techniques to complete — cannot be overemphasized. 


Before a systems analysis can be started a foundation for it must be estab- 
lished. This includes determining the needs, objectives, and approach to be 
used, and the organization of the project folder or notebook. 


The first step in the life cycle of a new system is the identification or determi- 
nation of a set of high-level needs and objectives. 


Initially someone has an idea or a need of a general nature and an analyst is 
called in to quantify or factor the general conceptions to specific, tangible 
components. 


Generally, the needs or problems surface because of: 
I. New ways of doing business caused by: 
eNew technology 
eNew products 
eCompetition 
e New laws or regulations 
II. Consolidations/mergers 

III. Need to reduce costs/improve profits 

IV. Revised forecasts, errors, lack of planning, deficiencies, false assump- 
false assumptions or understanding in existing systems, operations, or 


procedures, etc. 


V. Insufficient information, communications problems, faster and/or more 
accurate responses required, etc. 


At this point a high-level idea, need, or objective has been formulated for 
some reason, and it is up to the analyst to start the investigation/analysis 
(Figure 1). 


i. OBJECTIVES 
The objectives of the system are to: 


. Reduce rework and finished goods inventory of “‘Built-Not-Shipped”’ 
machines for current and future high volume products by controlling 
release of customer orders, and generation of paperwork to manu- 
facturing. 


. Eliminate indirect personnel required in paperwork update cycles 
for “‘Hard Cards”’ (customer orders). 


. Reduce paperwork costs for ‘‘Hard Cards’’ (customer orders). 


. Provide realtime status tracking of machines and customer orders for 
high-volume products throughout the manufacturing process. 


. Control disposition of finished machines to ensure no machine is 
shipped that has had order cancelled or altered after release and is 
not built to the customer requirement. 


Figure 1. An example of some high level objectives. These are, in effect, the primary 
purposes for developing the system 


Approach 


There are a number of principles, techniques, or approaches that can be used, 
depending upon the analyst’s background and experience and the nature of 
the assignment. It should always be remembered that, in most instances, 
good sound logic and common sense are key ingredients for any system. 


Project Folder or Notebook (Documentation) 
The development of a project folder or notebook is, perhaps, the most useful 
tool or idea in good systems analysis. Done well, the project itself soon falls 
into place, and the analyst usually knows where things stand, and what to do 
next. In addition, if someone else should have to pick up the project, it 
becomes relatively easy to do so, minimizing original work loss. In time, the 
following 17 elements will usually be part of the project folder. 
1. General Project Assignment Sheet 
This document should “start the ball rolling”. It should represent a general 
summary of where to go, what to look for (or at), and any constraints applica- 
ble. This, or something like it, is usually prepared when the analyst first gets 
the assignment. 
Items to be included on the sheet are: 
e Date assignment given 
e Target dates or time constraints 


e Originator of project 


e Analyst(s) assigned (name, location, phone, etc.) 


2. An Organization Chart 


° Overall objectives 
e General area or areas to study 


e Prime Contact: 
Name 
Address/location 


Position 
Phone 


e Secondary contact(s) 
Name 
Address/location 
Position 
Phone 


¢ Problem area/functions/objectives to be covered in the analysis 


e Pertinent notes/comments 


This may be invaluable in determining whom to see about what. This 1s not 
to be looked at as merely a “who reports to whom list’, but, it should be 
developed as both a reporting structure and high-level contact or personnel 
reference data sheet. It should contain such things as: name, phone no., 


division or organizational unit, title or position, area of responsibility or 
speciality, location, etc. 


3. An Approach, Schedule, or Outline 


4. Interview Sheet 


This document should show: whom to see, when and for what purpose; what 
to read or study, when and for what reason; where to visit, when, and the 
objectives of each visit, tour, or meeting. 


It should be a routine practice to keep accurate notes of each meeting, inter- 
view, or work session. Before each meeting/interview, record briefly whom 
to see, subjects to be addressed, desired objectives, and significant points, 
comments, and needs to be covered. By determining this information in 
advance, you will be in a better position to limit the meeting to appropriate 
subject(s) and avoid discussions that have little bearing on your needs. 


During the meeting/interview, it is best to make notes concerning all that 1s 
covered. Your prior knowledge of the subjects to be discussed should mini- 
mize the effort and time needed to take notes. 


After the meeting/interview, compare your notes with the previously deter- 
mined subject(s) and objective(s) to ensure that they were properly covered. 
If not, you may need to schedule another meeting. 


In many instances, the interview sheet can be closely tied in with an 
area/systems/operations analysis sheet (see element 6). 


5. Glossary 


In studying an area, one usually soon learns that a specialized vocabulary 
exists for almost everything. It is frequently necessary to develop a glossary 
so that the analyst can communicate effectively and be able to read and study 
information intelligently. 


Following is an illustration as to what the abbreviation P.O. can mean to 
different people. Several of its dictionary definitions are given along with 
some common industry meanings. As can be seen, considerable confusion 
could result if there has not been agreement on the meaning of the abbrevia- 
tion before a study is started. 


Term/ Abbreviations Literal Meaning Definition/Use 


P.O. Purchase Order An order... 
P.O. Petty Officer 

P.O. Postal Order 

P.O. Post Office 

P.O. Plant of Origin 

P.O. Plant Order 


6. Area/Systems/Operations Analysis Sheet 


7. Overall Summary 


8. Examples or Illustrations 


9. Procedures, etc. 


This document is especially useful in “keeping on the right track” when 
holding interviews or analyzing documentation. It should include such items 
as: system/area/or operation name and abbreviation (or acronym); a list and 
description of current problems, including why they exist; a list and descrip- 
tion of anticipated problems, and why they are foreseen; goals or objectives to 
reach; current or future constraints; references to formal documentation; etc. 
Be certain to record date and attendees or interviewees. 


An overall summary or description of the system/area/operation and its 
main use, mission, or function are also important to obtain. User manuals 
and operational flowcharts, if available, are usually quite helpful in this 
respect. 


Copies of reports, forms, cards, input (source)/output documents, etc., should 
be obtained. The analyst should determine how and why they are used, their 
frequency of generation, and the system they go into and come from. Perti- 
nent field definitions should be developed where applicable. pamplss¢ of 
forms should show actual data/entry/output usage. 


Copies of procedures (local, divisional, and corporate), company policies, 
government regulations (federal, state, county, city or foreign government), 
technical or trade reports or write-ups, program documentation, application 
briefs, and the like should be obtained. 


10. Basic Technical Documentation 


Acquire all the technical information available. This includes: 
e File formats 
e Systems flowcharts 
e¢ Operational flowcharts 


e Program write-ups/systems overviews 


Unit record (punched card data processing) (PCDP) procedures 
e Screen design displays 


e Any other available/required information 


11. List of Data Processing Equipment and Personnel 


12. Hardware Descriptions 


13. Software Support 


Be certain to determine the available DP equipment and staff. Draw up a list 
of available or “in use” equipment, and a list of planned equipment. Items to 
be on this list should include equipment name, type, model number, number 
of units, manufacturer, location, capacity, special features or options, overall 
use of equipment and specific use as it relates to the area in question or under 
study, hours used per day, shift usage, weekend work, remote usage, preven- 
tive maintenance time, etc. 


The analyst should include planned removal dates, if any equipment is being 
taken out, and disposition of the removed equipment; planned installation 
dates of any new equipment due in, its location, use, and other pertinent 
factors. 


You should also make a list of DP personnel, including the number on each 
shift, how many work overtime or weekends and why, etc. Skill levels should 
also be considered. Should there be an educational program on new equip- 
ment before we can implement the system? Will there be a need to change 
the distribution of personnel between shifts? 


NOTE: In the full scope of a true systems analysis, not only computers, 
terminals, modems, controllers, and input/out devices are noted and exam- 
ined, but such things as TWX, facsimile reproduction and/or printing equip- 
ment, microfilm or microfiche equipment, general office and business ma- 
chines (such as calculators and addressing machines) are reviewed. 


Hardware write-ups or descriptive information. 


Software and/or applications write-ups. 


14. Pending or Problem Section 


A “Question’’, “Need to Know’, “Don’t Understand’, or ““Need to Resolve” 
section. This section should contain: (1) The things that an analyst needs to 
know or do, but have not yet been included in one of the more formal lists, 
(2) discrepancies and contradictions from one interview to another, or be- 
tween systems flows and people’s comments, or from documentation pack- 
ages to procedures, and (3) areas that the analyst thought had been fully 
covered, but now more data is needed. 


15. Peripheral or Supplementary Programs 


Although much of the information should surface as a result of the material 
gathered for the examples or illustrations portion (Element 8), it is sometimes 
useful to develop a special package of information regarding supplementary 
programs. Since the output of many of these types of programs often 1s not 
well known, or distributed, it is wise to ask in interviews if such programs or 
languages as RPG, GIS, APL, etc., are used, and if so, determine who writes 
them, who gets the output, etc. Often replacing this type of program is 
difficult but can sometimes save a substantial amount of money. Sometimes 
in designing a new system, it becomes mandatory to see that such utility-type 
user software is available (or, possibly, retained). 


16. Interfacing Impact or Interfacing Requirements 


It is essential that the whole impact of a system be viewed, and that it not be 
looked at from one area or perspective only. That is, in analyzing a system, 
its needs and deficiencies, the analyst must also look at its interfaces with 
other systems. Very few systems are truly totally independent; and this is 
especially true of those systems that support more of a business or manufac- 
turing environment than a scientific one. 


Frequently, when one looks at a particular area (say what IBM calls a 
“function” or “project” in a plant), one finds that, in fact, it is served by 
several, if not many, DP systems; some of which are dedicated primarily to 


support that area, and some designed to support other areas. 


It is imperative in analysis, as well as in design, to look at the interfaces 
involved. Frequently, the problems are not with a system designed to support 
an area, but with a system that interfaces with it, or with the interfacing 
between systems. In studying needs and deficiencies of a system, they should 
be viewed with respect to any interfacing needs with other systems or 
subsystems. 


17. Potential Goals and Objectives Checklist 
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A checklist or summary of potential goals, objectives, or needs is an essential 
part of the folder. This is really the ultimate objective of the analyst. It is 
quite helpful while analyzing an area or conducting interviews to have a list 
of categories under which improvements can be made. This is useful in the 
justification stage, too, for these same categories can be (in fact, must be) 
quantified or evaluated to justify the system. 


In general, potential improvements fall under three broad categories: 
I. Reducing costs 
II. Improving the information 

III. Improving control 

These can be further expanded into a meaningful checklist. 


I. Reducing costs 
A.Reducing people-oriented costs 


e Reducing overtime 
e Reducing the number of people needed to perform a job 


e Changing the nature of a job from more skilled to less skilled require- 
ments, resulting in less costly approach 


e Reducing the effort involved so one person or a group can do more jobs in 
less time 


These can often be accomplished by: 


e Decreasing the workload by automating the job (“put it on the 
computer’’) 


e Freeing professional or highly skilled people from routine work 

e Keeping output on schedule (minimum downtime) 

e Reducing the complexity of a job (reducing the number of manual opera- 
tions involved, or the difficulty in filling out forms or inputting informa- 
tion; or having the system automatically input data such as date, time, 
etc.) 

e Combining similar jobs and eliminating redundant operations 


B. Reducing equipment or supplies costs 


e Reducing the number of reports (combining several) 


Reducing the size of reports (going to exception reporting, inquiry, etc.) 


Reducing the frequency of reports (from daily to every other day, from 
quarterly to on request, etc.) 


Reducing distribution of reports (sharing, use of older reports, etc.) 


Reducing amount of equipment used (more computer-driven machines or 
operations) 


Increasing effective utilization of DP equipment (additional shift work, 
better configuration software support, improved job stream, distributed 
networks, etc.) 


1] 


II. Improving the Information 


Ili. Improving Control 
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e Reducing space (going from lists to microfiche, from manual files to 
inquiry into the system or special reports, from routine reports to “‘as 
requested’’) 


¢ Reducing direct using space (having computer used as test equipment) 
e Reducing or combining forms, cards, etc. 


e Minimizing redundant operations (combining data bases, files; providing 
better user output) 


e Changing the type of paper used (quantity, thickness, color, size, etc.) 


e Providing more information and/or better reporting elements 


e¢ Providing more accurate information (more legible documents, better 
edits and audits) 


e Providing the information faster 
e Allowing more flexibility in selecting outputs (user-created utilities) 


e Improving exception reporting (showing only the trends, results, prob- 
lems, etc.) 


e Creating measurement and analysis reports and transaction histories 
rather than just status or summary reports 


In many cases, this is taken to mean a better understanding of what is hap- 
pening, when it happens, where it happens, to whom, and why. That is, the 
overall impact, or control of the operation. Many analysts believe that this 
type of control is really best handled by improving the information (as 
addressed earlier). 


The other side of the control problem has sometimes been referred to as 
“asset protection’. It involves techniques to prevent embezzlement, fraud, 
theft, misappropriation of company assets, and the like. It may also include 
such things as computer control of external and internal entrances, security 
clearance levels, and so forth. 


Getting Started 


Once the project folder has been started, what are the various means for 
information gathering? 


How and Where to Get Information 


Direct Interviewing 


This includes in-depth discussions, questions, and meetings with the individ- 
uals directly responsible for the jobs. It may be necessary to interview all 
levels of management and technical people including administrative, produc- 
tion, and support personnel. : 


Report and Documentation Review and Analysis 


Physical Review 


Studying flowcharts, procedures, user manuals, forms, job responsibilities, 
management and company objectives, reports, policies, regulations, statistics, 
physical plans, etc. 


Actual tours, demonstrations, and walk-throughs of the various areas to be 
reviewed. Physically seeing the areas in operation is frequently of great 
value. 


Peripheral or Supplemental Information 


e Formal company reports 

e Industry reports 

e Trade journals 

e Technical reports 

¢ Government regulations, requests, reports 
¢ Catalogs 


e Program documentation 


¢ Application write-ups and briefs 
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General Factors to Consider in Data Gathering 


Interviewing Techniques 
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In utilizing the techniques mentioned in the preceding section, there are some 
important factors that can be quite helpful. 


The analyst should record all information as presented. Do not prejudge, 
degrade, or jump to conclusions (either overtly or covertly), or otherwise 
qualify the data presented. 


Ask questions to clarify what is not clearly presented. Be sure you have 
heard what was said, see clearly and understand what is being done, and 
obtain a feel for each person’s understanding of why that person is doing 
what is being done systems-wise. (A person’s understanding may not be 
quite correct, but it may give a valuable clue as to what is right or wrong 
and why.) 


e Try not to problem solve at this point. This is a learning step to determine 


what is being done, how it is done, by whom, and why. 


The analyst must study the documentation: forms, reports, flowcharts, 
procedures, etc., to see how things are done. Frequently the way a man- 
ager thinks a job is done, the way a flowchart shows it, the way a proce- 
dure indicates it, the way an analyst thinks it should be, and the way it 
actually is done are not identical. Note the various discrepancies. Try to 
determine when the documentation was done, by whom, and in what 
capacity. Try to determine why the variations, if any, exist. 


A total approach should be taken. All factors should be addressed as 
much as reasonably possible from a first-hand approach. Secondary 
sources are not necessarily reliable. 


If appropriate, several people doing similar jobs should be interviewed. 
The same overall job or job title does not always imply the same tasks, 
responsibilities, orientation, or needs. Be careful of apparent similarities 
that are actually differences. 


The significant events, ideas, problems, or needs should be highlighted as 
the analyst proceeds. This may take several iterations, but is well worth it. 
It highlights less obvious relationships and problems and clarifies the 
situation in the analyst’s mind. 


And finally, the whole thing should be “put together”. The operation 
and/or system should be understood thoroughly, and to make certain of 
that the area under study should be flowed out, that is, flowchart or 
describe the operation as it is. This will show not only what is known, but 
should highlight what may have been missed or was undetected. Remem- 
ber, this is the system as the analyst now understands it to be. 


How and where to obtain information has been reviewed, as well as some 
general factors considered in information gathering. Now, some techniques 
that can aid the analyst in interviewing. 


The analyst should always be prepared and should know whom to see, 
where the interviewee is located, and for what purpose the meeting or 
interview is going to take place. Make a checklist of questions to ask 
during the interview. 


Make an appointment for a specific time, and be punctual. Call if de- 
tained or if a cancellation is necessary. Set aside enough time to get the 
desired information (one cannot obtain two hours of information in 30 
minutes). Advise the interviewee beforehand of the purpose for the 
meeting so there will be time to prepare for it. Sometimes, by knowing 
the purpose, the interviewee will direct the analyst to someone more 
knowledgeable on a particular subject, thus saving time for both parties. 


Have permission to see the interviewee and make sure there will be no 


contractual problems created by your meeting. Assure the person that it 


is permissible to talk to the analyst about the subject. This is especially 
important when talking to clerks, administrative personnel, and produc- 
tion workers. 


Be aware that approach is all-important in many cases. It is a good idea 
to start out with an explanation of the purpose for the meeting and the 


analyst’s overall job. Sometimes the right perspective helps dramatically. 


Try to build confidence and respect. Tell the interviewee why the study 
being made. 


Be friendly, courteous, and cooperative. Abruptness rarely, if ever, 
obtains the desired information. 


Do not let the interview become a gripe session. The analyst is there to 
gather data, understand the job, and identify problems, not to solve 
personnel problems or deal with pent-up emotions or old feuds. Every 
effort should be made to stick to the purpose of the meeting. 


Stress the current environment. Too often, people try to go to the past. 
Do not fall into that trap. Deal with what is happening now. 


Do not be critical of the current process. Change will not always be 
made. Be open-minded, receptive, and positive. 


Do not appear to be a “know-it-all”. Be knowledgeable, but remain a 
“student”. | 


Readily acknowledge good points; give “credit where credit is due’; be 
appreciative for help. 


If the interview turns into a technical problem solving session, reach an 
agreement with the individual before leaving. At the least, know where 
the agreements and disagreements lie and why. Do not leave with the 
interviewee expecting one thing, and the analyst another. 


If the analyst feels that some individuals have done a good job or have 
gone out of their way to help, thank them and their managers. 


iS 
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Needs and Objectives 
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e It is also a good idea to let the individuals know if any of their ideas are to 
be used or implemented. 


e Find out the experience level and background of the interviewee in the 
area under study. This can help the analyst to avoid talking up or down 
to someone. 


e Always keep in mind the objective of the study and the magic questions: 
- What do you do? 
- Why do you do it? 
- How do you do it? 
- Do you have any problems? 
- What do you think could be done to help you? 
- Do you like this job? Why? 


If you could manage this department, what would you do?...what changes 
would you make? 


What do you need to know to help you do a better job? 


At this point, the analyst should know the system and have a good under- 
standing of its deficiencies and enhancement possibilities, especially as 
related to specific management objectives. 


It is from this knowledge and experience that the overall needs and objectives 
are drawn up. Sometimes they are of major importance, involving whole new 
systems or radical changes in procedures and the operating environment. At 
other times the current system needs to be modified or enhanced. And of 
course, in some cases, the system is found to serve its purpose well, but the 
users simply are not using it the way it should be. In that case, education and 
management involvement will probably suffice in making the necessary 
improvements. 


In considering how needs and objectives are determined, a “checklist or 
summary of potential goals, needs, and objectives” should point the way 
toward what to look for. Experience, expecially working with a trained 
analyst for one or two projects, is the best method for really learning. 


It has also been said that the best technique for determining what is needed in 
a system is role playing. That is, once the operation or system is learned, the 
analyst should ask, from the position of the worker performing the job, 
“What would I need to do the job better, faster, more easily, more accurately, 
or to save (more) money, etc.? Likewise, the analyst should ask, from the 


-. position of the various managers over an operation, questions such as: 


“What can be done to measure what is happening?” 
“How can I measure the productivity of an operation?” “What can be done to 
reduce costs?” 


Justification 


Potential Savings Categories 


“To see that the employees have what they need when they need it?” 

“To improve my knowledge of the operation?” 

“To know the workload volumes, and how they compare to previous time 
periods and current projections?” 


In short, the analyst should ask the kind of questions an aggressive, conscien- 
tious employee would ask while trying to improve the operation at every level 
of responsibility. 


Once the overall needs and objectives have been determined, they must be 
evaluated from an economic standpoint. This is usually done in two stages or 
composed of two parts. 


|. An estimate of the gross user or operational savings 


2. An estimate of the costs to develop, implement, and maintain the new 
system or any proposed changes or enhancements 


The first figure should be netted against the second to see whether the 
project is worthwhile, or what the return on investment (ROI) would be. 
The estimate should be done by individual objective or need to keep the 
various areas in perspective. That is, it may be advantageous to program 
some things, but not others. (It is an axiom that almost anything can be 
programmed; it is just a matter of whether the savings justify the pro- 
gramming costs involved.) 


A systems analyst, having full responsibility for a job, would normally 
perform both aspects of the evaluation. 


In some instances, it is the user analyst’s job to assess the user savings, while 
the programming area estimates the development and maintenance expenses. 


To determine what the potential savings should be, the analyst goes back to 
his “checklist of potential goals, objectives, or needs” and looks at the areas 
identified. Assuming the needs were met, the analyst then quantifies the 
savings. 

Generally, savings for justification fall into three broad categories: 


I. Personnel savings 


A. Regular — determine the number of hours saved and equate it to 
dollars. 


B. Overtime — determine the number of hours saved and equate it to 
dollars. 


II. Non-personnel savings 
A. Equipment: trucks (external and internal), machines, tools, comput- 


ers, computer peripherals, desks, file cabinets, parts, raw material, 
business machines, conveyors, etc. 
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Cost Avoidance 


Cost Estimates 
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B. Supplies: forms, computer cards, paper, repair tools, repair equip- 
| ment, office supplies, etc. 


C. Cost of goods purchased: cost value-analysis programs, investing, 
obtaining or making loans more favorably, telephone/wire services 
usage, and better buying techniques, accounting practices, inventory 
control approaches, etc. 


D. Building costs: reducing owned or leased space for material, equip- 
ment, people, parts, supplies, files, etc. 


E. Supplemental costs: insurance, taxes, security, utilities, etc. 
III. Control 
A. Asset protection: reducing theft, pilferage, embezzlement, etc. 


B. Increased operating control: how much of what is where, when, and 
can the accuracy of that data be proved? 


In addition to the three categories listed above, potential savings are some- 
times qualified under “cost avoidance”. This term is generally applied to 
those areas where something is forthcoming, and a savings arises, or a Cost is 
avoided if a new system, method, or procedure is implemented. This occurs, 
for example, when products are transferred, building schedules increase, new 
government requirements are enacted, or company policy changes (especially 
accounting or auditing). The qualification itself is still grouped under the 
various Savings categories, but since the cost is not a current one, it is consid- 
ered as a “cost avoidance”’. 


For purposes of this section, the factors involved from a programming and 
data processing viewpoint are reviewed lightly. In essence, an estimate 1s 
made of the time (generally in man-hours, man-months, or man-years) it 
would take to provide the program design and coding, and to do the program 
(unit) and systems testing. This is converted to dollars by using an applicable 
rate. Time is also factored in for file initialization effort as well as parallel 
runs and file cleanup. 


Computer time for assembling, testing, file cleanup, initialization of files and 
regular run time is also calculated and a dollar value attached to it. Support- 
ing hardware costs, such as peripheral devices, cables, telephone and mo- 
dems, etc., are also figured in. And these are netted, of course, against any 
equipment or personnel costs they would replace. 


Supplies, forms, cards, and the like should also be considered: those that 
need to be added and those that will be eliminated and/or combined. In 
some instances, the cost of direct user involvement is also factored in. 


From a systems engineering or total cost consideration, some individuals 
believe that the analyst’s time must also be considered. 


The Proposal 


What we have just covered is variously referred to as a study, a proposal, a 
preliminary survey, or a high-level overview analysis. 


The prime mission of the study is to determine what can be done to improve 
an operation and to get an idea as to whether it is practically feasible to 
implement such recommendations. 
In some environments, the analyst: 

¢ Determines the needs and objectives 

¢ Develops the user or gross justification for them 

e Presents the findings to management 


e Obtains the approval to proceed 


A complete sizing yielding a netted justification or estimate is included in the 
study or proposal, and a formal presentation or package is given to manage- 
ment showing: 


e What is recommended 
e Why the recommendations are made 


¢ What the costs to develop and maintain the recommendations are estimat- 
ed to be: people, equipment, etc. 


e A proposed schedule 
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Implementation 


At this point, assuming an approval is given, formal design work begins and a 


plan is developed. Depending upon the size and scope of the mission, and 
the nature of the job involved, either a General Installation Plan (GIP), 
covering all facets of the design and installation, is developed or a Prelimi- 
nary Installation Plan (PIP) followed by a Detailed Installation Plan (DIP) is 
prepared. 


Preliminary Installation Plan 


Detailed Installation Plan 


Fundamentals 


Overview 
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A Preliminary Installation Plan (PIP) is generally developed for major systems 
or significant systems modifications. The PIP is used as a plan or guide under 
which specific systems functions and needs are identified and structured, 
detailed manpower and cost assessments are made, interfacing requirements 
are delineated, initialization techniques specified, file cleanups outlined, 
educational requirements formulated, testing plans developed, and the 
overall plans and specifications brought together in one package. 


The results of a PIP are best highlighted by recognizing that it provides: 
e Specifications of what to do 
e Targets of when to do it 
e Manpower required to accomplish it 


e Costs anticipated 


A Detailed Installation Plan (DIP) is usually used as a specific plan under 
which the actual design, programming, testing, installation, and education are 
performed. 


The results of a DIP are the actual implementation of the system itself. The 
DIP leads more to “how” than “what”. For example, how the system works, 
how the file initialization will be accomplished, how the interfacing will 
work, etc. 


There are a number of fundamental items that are necessary in designing a 
system. For the most part, they are addressed both in a PIP and DIP; therefore 
an attempt will be made to look at them and their various aspects from a 
generalized level. 


Basically, all systems can be represented schematically as follows: 
Traditionally, in designing a system, the analyst works somewhat backward. 
He performs “3” then “1” then “2”. That is, the output is specifically de- 
fined, the input requirements are determined, and finally the processing logic 
necessary to transform the input into the needed output 1s specified. 


This sequence represents systems analysis and design in a nutshell. 


Using this concept, the first thing to look at is the outputs needed. Outputs 
can be a variety of things, including the following: 


e Reports 


e Terminal responses or displays 


Updated files 

e Interfacing files (disk, tape, card, etc.) 

e Microfiche 

e Error identification 

e Input listings 

e Cards 

e Control information 

e Audible alarms 

e Electrical signals 
One of the first things to do is to determine the effectiveness of the existing 
output. The prime questions to ask are: Does the output meet the needs of 
the business 1n today’s environment and in the foreseeable future? If not, 
what is needed? When is it needed? And what is its value? 
If the area under analysis does not have an automated system, the questions 
are virtually identical: What is needed to run the business today and what, in 
our opinion, are future needs? Additionally, what is the value of knowing the 
answers to these questions? 
This is a very detailed and time-consuming task, generally involving weeks, if 
not months of effort. It is truly the most important phase in terms of ultimate 
value to the business. For, if we do not know what is needed and its value, 


nothing else of worth can be developed. This probably cannot be stressed too 
strongly. 
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Input 


Processing 


Output - Detail Level Forms 
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Input requirements are a natural outgrowth of the output needs once what is 
needed has been determined. The analyst must then concentrate on how to 
get it. In effect, data comes from: 


e Documents or files that already exist 

e Documents or files especially created for a particular purpose 
e New or modified fields within files 

e Recording actions taken (original transactions) 


It should be realized that a major portion of the analyst’s work is concerned 
with obtaining the information necessary to provide the needed output, and 
ensuring that it is available in a data processable format. 


Once the output and input have been formulated, logic or specifications must 
be developed to convert the input to the proper output. This can be done by 
a variety of methods, depending upon the situation. One of the more com- 
mon, yet effective, methods is sometimes referred to as the “dictionary” or 
“field definition” approach where each field appearing on the various re- 
ports, forms, displays, and so on is defined. The definition provides the key 
to the processing required to produce the output field. 


According to Webster, a form is considered to be “a printed...document with 
blank spaces for insertion of required or requested information”. (Obviously, 
an interactive terminal display can perform the same functions as well as 
“computer edit” the data for validity as it is entered.) 


Considerable time can be spent in covering the many factors that are in- 
volved in good forms design and control, especially when both input and 
output forms are considered. For purposes of eliminating duplicate effort, 
both types of forms will be more or less addressed together. Following are a 
number of pertinent factors in forms design: 


1. First get some basic idea of the general form size and shape, and proceed 
from there. 


2. Start with a blank printchart (GX20-1818) and lay out what the computer 
needs to print, and where. Most analysts put an “x” in each space to be 
computer printed. Decimals are usually represented by a caret or trian- 
gle at the bottom of the print block. 


3. Next write in the material to be preprinted by the forms supplier, doing 
such things as field headings and descriptive data first, and then filling in 
the background or “boiler plate” type of data. 


Note: The preprinting refers to the printing done on the form by the 
printer or supplier, as opposed to the printing done by the computer. 


4. If some of the words, sentences, paragraphs, columns or field headings, 
logos, illustrations or the like already are printed somewhere and are 
more or less the correct size, cut them out and appropriately paste them 
on the layout sheet. (Cut the printchart to the appropriate form size.) 


5. Determine whether overleaf preprinting is necessary. Frequently, 
government regulations, company policies, legal requirements, space 
restraints, clarity, or costs necessitate more data than can be put on one 
side of a form. Preprinting on the back is often quite helpful or even 
mandatory. 


6. Note whether forms are to be controlled, accounted for, or used as 
cross-reference documents. If so, sequential prenumbering, preferably in 
red, usually at the top, may be advisable, or necessary. 


7. Determine the number of ultimate users (uses) of the form, so that the 
correct number of copies (sheets of a form) can be ordered, with the 
appropriate number of carbons between them. 


8. If forms are to be multiple copies, each page should have the user or 
department it goes to printed on it, preferably at the bottom. It is impor- 
tant that people can distinguish one page from another, and that the 
printing shows up distinctly and clearly. 


9. The more use and/or needs of the business a department has for a copy 
of a form, the closer to the top that copy should be. 


10. Be certain to assign a form control number to each form developed. 
Also indicate a revision number each time the form is updated. In some 
instances, the analyst should be sure to check with the location’s forms 
control administrator. 


11.Check inventory supplies and systems availability to schedule the new 
forms in at the proper time without undue expense. Remember to see 
that forms come in at, or slightly before, testing time (as opposed to 
installation time). 


12. Estimate annual use and order about three or four months’ usage plus 
enough forms for testing and educational needs. (Do not order too many 
forms the first time because modifications may have to be made due to 
last minute changes.) Also, be aware that people have a tendency to 
stock up when new forms or major modifications are installed, that 
testing purposes generally take many continuous forms, and that setup 
each time the form is run will usually use a number of forms. 


13. Order well enough in advance to ensure the forms are received ontime. 
Lead times vary, but three to five months may not be unusual when 
proofs are required and paper is in short supply. In emergency situa- 
tions, forms can generally be obtained sooner, but usually proofs are not 
provided, and the cost increases proportionally. 


14. Request proofs and review them in detail. Double-check everything, 
especially such things as abbreviations, commas, block or field size, form 
numbers, addresses, form size, overleaf data, crimping, etc. 


15. Specialized applications may require carbons where some or all informa- 
tion passes through to various copies, and not to others. Consult with the 
proper people, if necessary, but the possibilities are sometimes quite 
varied here. 


16. Note such things as different techniques for combining sheets. Crimping 
is excellent. 


17. For forms that must be hand decollated, be certain not to let the carbon 
go all the way to the edge of the sheet--leave room for the hand to hold 
the paper while breaking it apart. 


18. For private, confidential, or restricted use of some data on forms, consid- 
er using “blacking out”, tear strips, or partial carbons. 


19. If the document is a “master sheet” that will receive wear, have addition- 
al data stapled to it, be repetitively pushed into files, etc., use “hard” or 
thick paper rather than paper of regular thickness. 


20. Arrange the input, as far as possible, 1n a logical sequence for input 
documents. Make it as similar to the input flow as is reasonably 
possible. 


21. Notify the (potential) users in writing of the new form or screen format. 
Tell them when they should start using it and include an illustration. If 
it is an input form try to provide instructions for filling 1t out and an 
example of one correctly completed. Be sure to emphasize required 
versus optional fields. 


22. Clarity of the form is important. When a form has been designed for 
manual input, give it to someone and ask for it to be filled out. If the 
individual has trouble or asks too many questions, something 1s wrong. 
The form should be self-explanatory. Perhaps fields should have more 
explanation, better wording, dashes used--one for each letter or numeral 
in a field rather than a straight line, or blocks for lettering, etc. Also, run 
the form by the input specialist who will be using it. What does that 
person think of it? What suggestions for its improvement? 


Do not forget the programmer. Something may have occurred since the 
original specs were drawn up to necessitate an alteration, and this data 
may not have filtered back to the analyst. Give the programmer a 
_chance to review the form. 


Some analysts develop a checklist or signoff sheet to go by. Each affect- 
ed area is asked to review and approve the form before the formal pur- 
chase order is placed. Include both the name of the prime user and the 
manager of each area on the forms signoff sheet. Ask such questions as: 
“Does it have everything on it?” “Is anything unnecessary on it?” 


23.If a copy of a form is to be filed in a notebook of some sort, rather than a 
file folder, have the form prepunched with appropriate holes. 


24. When the draft of the form has been completed, ask the key question: 
“Has all standard or repetitive data been designated to be preprinted?” 


25. Review the draft to see that there is ample room between lines, blocks, or 


preprinted material for the computer printing without cramming. Be 
sure to leave some leeway. 


26. For many input documents, it is sometimes advisable to preprint the 
routing and/or the DP job number on the form. Also, include any 
unique or special instructions. 


27. Determine what, if any, approvals or signatures are needed in the proc- 
essing of the forms. (This does not mean approval of the form design, 
but approval of whatever is on the form once it is being used.) Clearly 
specify who is to sign where. 


28. Provide for adequate margins — top and bottom, right and left sides — 
both for computer forms and manual ones. 


29. If it will take several sheets of a particular form to complete a grouping, 
have the computer sequentially number the sheets in each group. (This 
is perhaps more of a specification requirement than a forms tool, but it 
can be quite helpful if problems arise.) 


30. For forms that are to be mailed, place the name and address in such a 
position that window envelopes can be used, whenever possible, thus 
saving much addressing effort. 


31. If the form is to be filed, see that the sequence numbers by which filing is 


to occur are prominently displayed, usually at the upper right or left. 
(The form control number is not always the sequence that is used for 
filing — different areas or departments may use the same form and file it 
differently for different purposes.) 


32. Give an appropriate, meaningful title to the form. This not only helps in 


general usage, but if the form is misplaced or DP routes it to the wrong 
area, the title can give a good clue for determining whom to call. 


33. Again, when the draft version is completed, if not before, check to make 
certain that several forms cannot be combined into one. Likewise, 


objectively view the form to see whether too much is on it — does it try to 


serve too many purposes, and should it really be two forms? Two keys, 
here, are size and clarity. Is it standard size, and is the form easy to use 
and fill out? 


34. Be careful on machine decollating and machine bursting instructions for 
continuous forms. While most forms are machine bursted, the nature of 


the form and its use will determine whether it is better to automatically 
or manually decollate it. Some multiple copy forms require signatures, 
approvals, or additional typing before being sent out, and therefore it 
would not be wise to automatically decollate them. Others, which 
require no manual modifications, probably should be machine bursted 
or machine cut. | 
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Purchase Order Examples 
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35.1f certain fields use codes, it is sometimes helpful to print the codes and 

what they stand for on the form. Also, boxes or places to select, circle, or 

check are sometimes quite helpful in saving time and in providing 
clarity. | 


36. Make certain that significant information is clearly spelled out and is 
printed well enough to attract the right attention; for example, black or 
heavy lettering, varying the positioning, increasing the size and/or type 
of lettering, etc. 


37. If the form is an output form from a computer printer, be certain to 
know the types of printers that can be used. Review the printer capabili- 
ties and restrictions for such things as form size, print speed, number of 
copies, paper thickness, etc., that the unit can handle. 


38. It is generally recommended that the analyst who 1s inexperienced in this 
area review a number of various kinds of forms to get ideas. Do not 
restrict yourself to those forms similar to those being designed. It is 
technique as well as specifics that can help. Reference books and appli- 
cation manuals may also provide additional assistance. 


It has been said that an army moves on its stomach, and a business on its 
forms and reports. Indeed, there is no practical way to delineate the numer- 
ous forms or types of forms that a business uses. However, to illustrate some 
types of forms and various aspects of forms design, this section steps through 
two types of purchase orders, highlighting various points. 


Figure 2 shows a typical blank purchase order used by a Parts/Inventory 
Purchasing System. It is a three-part multicolored form that is used to order 
from a supplier or vendor something that is going to be used in manufactur- 
ing or producing a facility’s product. 
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INTERNATIONAL BUSINESS MACHINES CORPORATION 
SYSTEMS DEVELOPMENT DIVISION 


P.O. BOX 12195 ; 
RESEARCH TRIANGLE PARK, N.C. 27709 SUPPLIER NO. Pete GO ne meer 
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PURCHASE ORDER 
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1. ADDRESS ALL INVOICES TO THE ACCOUNTS PAYABLE 
DEPARTMENT. SHOW TERMS OF PAYMENT ON INVOICE. 
. SUBMIT ONLY ONE COPY OF YOUR INVOICE FOR PAY- 
MENT. 
| - SHOW OUR COMPLETE ORDER NUMBER, JOB NUMBER, 


PART NUMBER (IF ANY) AND QUANTITY ON ALL IN- 
VOICES, SHIPPING CONTAINERS, PACKING LISTS AND 
CORRESPONDENCE. 

RLY MARK CARTON CONTAINING PACKING SLIP. 


FREIGHT ALLOWED SHIPVIA 


TERMS OF PAYMENT 


JORDAN BUSINESS FORMS 


OELIVERY OATE 


UNIT PRICE 


ENGINEERING 
CHANGE NUMBER 


QUANTITY 


ittm{ CODE OR PART NUMBER DESCRIPTION 


Le 


op 


DO NOT WRITE BELOW THIS LING 


TRANSPORTATION ROUTING GUIDELINES *TOTAL. QUANTITY OF ITEM ORDERED AT PRICE SHOWN. 
(DO NOT INSURE OR DECLARE VALUE) 


v)@ 


DIRECT ALL INQUIRIES TO: PURCHASING DL- 


0 50 LBS. UNITED PARCEL SERVICE IF AVAILABLE (MAXIMUM SIZE PARTMENT 
NCH ab H : 4 
COMEDY Or ee CONTACT BUYER IMMEDIATELY IF EXCEPTION IS 
& TAKEN TO PRICE, DELIVERY DATE, QUANTITY, 
ORO 40 LBS PARCEL POST (ZONES 1 8) CASH TERMS, ETC. 
41 50 LBS. TRUCK ROUTING ON FACE OF ORDER 
51+ L8S. TRUCK ROUTING ON FACE OF ORDER IN LIEU OF MONTHLY STATEMENTS PLEASE 


FORWARD A COPY OF PAST DUE INVOICES (THOSE 
O'VER 30 DAYS) TO OUR ACCOUNTS PAYABLE DEPT. 


PRIORITY RATING 


PLEASE INDICATE FINAL SHIPMENT ON YOUR 
PACKING LIST WHEN AN ORDER IS COMPLETED. 


CERTIFIED FOR NATIONAL DEFENSE UNDER OMS REGULATION 1. 
SUBJECT TO THE TERMS AND CONDITIONS 


You are required to follow the provisions of OMS Regulations 1 and of all other- ON THE BACK HEREOF WHICH ARE INCOR- 
applicable regulations and orders of BOSA in obtaining controlled materials 

and other products and materials needed to fill this order, provided it contains PORATED AND MADE A PART HEREOF 

a DO and/or DX priority rating. INTERNATIONAL BUSINESS MACHINES CORPORATION 


.DO NOT BILL NORTH CAROLINA SALES/USE TAX. 
DIRECT PAYMENT CERTIFICATE NO. 238. 


BUY! 


925 > 0192-08 


Figure 2. A typical preprinted purchase order used by a Parts/Inventory Purchasing System 
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Figures 3A through 3C show the various sheets of the purchase order after it 
has been processed by the computer or typed. Figure 3A shows the front of 
the white first sheet, which is sent to the vendor after it is checked for accura- 
cy and signed. The standard terms and conditions that apply to the purchase 
order are printed on the overleaf of the first sheet. 


Figure 3B is the front of the second sheet, which is yellow in color. Note the 
distribution and copy number clearly preprinted on the bottom center. The 
preprinted information for the vendor on the lower section of sheet one is not 
needed by the recipients of the second sheet and is, therefore, not shown. The 
overleaf of the second sheet is used to record receipts against this purchase 
order. 


Figure 3C shows the front of sheet three and is Purchasing Services’ copy of 
the purchase order. It is green and the preprinted information for the vendor 
that appears on the lower section of sheet one is repeated here for the buyer 
to reference, if necessary. The overleaf of sheet three is blank. 


The string of holes on both sides of a form indicate that it is a continuous 
form for automatic feeding, as on a computer’s printer, for example. The 
holes are usually punched into tear strips that are removed after the form has 
been processed by the computer. In some instances, the holes on one side 
(usually the left) are also used for binding/filing the form after it has been 
distributed and, in those instances, the strip containing the holes is not 
removable. 


Figure 4 shows two continuous forms, just as they would be fed into a printer. 


The next form shown is a blank purchase order used by a non-production 
Maintenance, Repair, and Operating Supplies (MRO) Purchasing System. It is 
used to order items that will not enter the production process directly; office 
furniture, grass seed, preprinted forms, lift trucks, maintenance supplies, 
safety glasses, uniforms, and television cameras and receivers, for example. 
Because items such as these are usually charged to a department’s budget, 
there are copies of the purchase order for both the originating department 
and appropriations control (see Figure 5). 


Figure 5 shows an MRO purchase order that has an original and four carbon 
copies. The first sheet is white and is followed by sheets of yellow, salmon, 
blue, and orange. As shown in Figure 5, except for the vendor’s top sheet, to 
ensure proper distribution each sheet is labeled at the bottom in red ink. 


Figure 6 shows the originator’s copy of the purchase order shown in Figure 5. 
Note the arrow at the top left pointing to the field called “Dept.” That field 
will contain the department number of the originating department after the 
purchase order is printed. Then, the originator’s copy is folded and stapled so 
the department number and arrow show, and is dropped in the internal mail 
for delivery to the originating department. The need/cost for an envelope 
has been eliminated. 


In addition to the two tear strips, the top of the first sheet may also be re- 
moved to prevent irrelevant or even internal use only information from 
reaching the vendor. Figure 7 shows this top tear strip removed, and the 
lower right corner of the first sheet cut off to show how far the carbon extends 
in relation to the bottom of the document and the tear strip (which has also 
been removed from the extreme lower right). 
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Figure 3A. The copy of the purchase order sent to the vendor or supplier. The feed holes have 
been removed. 
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Figure 3C. Sheet 3, Purchasing Services copy of the purchase order 
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Figure 4. An example of continuous forms 
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PURCHASE ORDER 
INTERNATIONAL BUSINESS MACHINES CORPORATION 


SYSTEMS DEVELOPMENT DIVISION 
P.O. BOX 12195, RESEARCH TRIANGLE PARK, N. C. 27709 
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PROCUREMENT 


41 - 50 (BS. TRUCK ROUTING ON FACE OF ORDER. DIRECT PAYMENT CERTIFICATE NO. 238. 
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PLEASE INDICATE FINAL SHIPMENT ON YOUR 
PACKING LIST WHEN AN ORDER iS COMPLETED. 


i BUYER: 
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Figure 5. An example of a typical preprinted purchase order used by an MRO Purchasing System 
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INTERNATIONAL BUSINESS MACHINES CORPORATION [ 


PROJ./ JOB NO. ACCOUNT NO. DEPT. CHG.] APPRO. NO. 


SHIP TO: 


SYSTEMS. COMMUNICATIONS DIVISION 
P. O. BOX 12195, RESEARCH TRIANGLE PARK, N. C. 27709 


DATE PURCHASE ORDER NUMBER 


IMPORTANT 


DIRECT ALL INVOICES TO OUR ACCOUNTS PAYABLE DEPARTMENT, DEPT. 716, P. O. BOX 
12195, RESEARCH TRIANGLE PARK. NC. 27709. IN LIEU OF MONTHLY STATEMENTS 
PLEASE FORWARD A COPY OF PAST DUE INVOICES (THOSE OVER 30 DAYS). 

2. SHOW OUR COMPLETE ORDER NUMBER, JOB NUMBER, ITEM NUMBER, PART NUMBER (IF 
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others) length and girth must not exceed 100 inches. ; ; 

C. All‘others -Use carrier indicated in "ship via" block. 
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INTERNATIONAL BUSINESS MACHINES CORPORATION 


PLEASE INDICATE FINAL SHIPMENT ON YOUR 
PACKING LIST WHEN AN ORDER tS COMPLETED. 


FORM 925-2574-04 


BUYER: 


ORIGINATOR 


Figure 6. The originator’s copy of an MRO purchase order 
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SHIP TO: 


2 S222 Purchase Order z= =I 
INTERNATIONAL BUSINESS MACHINES CORPORATION 

SYSTEMS COMMUNICATIONS DIVISION @ 
P O BOX 12195, RESEARCH TRIANGLE PARK. N. C. 27709 


DATE PURCHASE ORDER NUMBER 


IMPORTANT 


DIRECT ALL INVOICES TO OUR ACCOUNTS PAYABLE PEO OF is OEPT 716. P.O. BOX 
12195. RESEARCH TRIANGLE PARK. NC. 27709 IN LIEU OF MONTHLY STATEMENTS 
PLEASE FORWARD A COPY OF PAST DUE INVOICES (THOSE OVER 30 DAYS). 

2 SHOW OUR COMPLETE ORDER NUMBER. JOB NUMBER. ITEM NUMBER. PART NUMBER (IF 
ANY). ANO QUANTITY ON ALL INVOICES, SHIPPING CONTAINERS. PACKING LISTS, ANO 
CORRESPONDENCE 

3. CLEARLY MARK CARTON CONTAINING PACKING SLIP. 

DIRECT ALL INQUIRIES TO’ PURCHASING DEPARTMENT. CONTACT BUYER IMMEDIATELY 

IF EXCEPTION IS TAKEN TO PRICE. DELIVERY DATE. QUANTITY, CASH TERMS, ETC. 


@ SUBJECT TO THE CONDITIONS ON THE BACK 
HEREOF WHICH ARE INCORPORATED AND MADE A PART HEREOF. 
FOB DATE MATERIALS 


VIA 
SHIPPING OTHER 
DESTINATION 
QUOTATION DATE CONFIRMS OUR PHONE ORDER TERMS 


QUANTITY PART NUMBER DESCRIPTION UNIT PRICE | PER 


. “ 
= 


#2739 


TRANSPORTATION ROUTING GUIDELINES 
(00 NOT INSURE OR DECLARE VALUE) 


A 0-50 Ibs. - United Parce! Service Use if available: If not. see below. (Maxi- 
mum size per package - 108 inches in length and girth combined) 


B 0-40 Ibs. - Parcel Post Zones 1 through 8 size limits - length and girth (be- 
tween first class post offices) must not exceed 84 inches: (all DO NOT BILL 
others) length and girth must not exceed 100 inches DIRECT PAY} 
C All others -Use carrier indicated in “ship via" block INT 


PLEASE INDICATE FINAL SHIPMENT ON YOUR 
PACKING LIST WHEN AN ORDER IS COMPLETED. 


FORM 925-2574-04 


Figure 7. A vendor’s copy of an MRO purchase order with the top strip removed 
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Error Identification, Processing, and Messages 
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One of the most important aspects of ai processing is the integrity of the 


data, so a great deal of attention should be placed on ensuring that only 
accurate, complete, and appropriate material is loaded on a file. 


To do this, the analyst must define what is not acceptable to the system and 
what to do when unacceptable information reaches the system. The analyst 
usually has three choices: 

1. The system can reject all the data. 


2. The system can reject some of the data. 


3. The system can print or display messages indicating the status of suspect 
information. 


Ideally, choice three should be combined with either one or two, depending 
upon the seriousness of the error. The type of equipment and nature of the 
systems design (realtime, online, batch, interactive language, etc.) may also 
play a role in the error identification and correction techniques. In some DP 
circles, error identification 1s classified under two broad categories: 

“Edits” and “audits” 


Webster defines “‘edit”’ as: 


“To alter, adapt, or refine, especially to bring about conformity to a stan- 
dard or to suit a particular purpose.” 


“Audit” is defined by Webster as a “formal...examination and 
verification.” 


From a data processing point of view, an edit is often thought of as a check 
on each individual field to ensure that it meets certain criteria. For example: 


1. No alpha characters in a numeric field 
2. No numeric characters in an alpha field 
Be No special characters or blanks in an alphameric field 
4. The existence of only special letters or numbers in a field — for example, 
only cards with “six” in column 80 should reach this program or that 
subroutine 


5. A “self-checking”’ routine is used to validate part numbers, etc. 


This is considered to be “conformity to a standard” or to “suit a particular 
purpose”’. 


An audit, from a DP viewpoint, is considered to be a check, not so much on 
the data itself (for example, a particular field), but on the relationship of one 
field to another. 


For example: 


e A sensitive part can be ordered only by analyzer X. 


A certain account code requires that a unit of measure field be input for 
specific purchase orders. 


An order originated in a nonproduction system cannot be altered by the 
production system. 


A transaction to delete a record is manually entered, but the record does 
not meet delete criteria. 


Certain account data is entered on an order, but source code or plant 
number, or commodity code, etc., requires another (different) account 


code. 


A final claim is entered against an order that has not been started. 


e A receipt is processed for an order that is not on file. 


e A file is used that has a date out of range or out of sequence. 


Good techniques for error identification include such things as: 


e For errors that are serious in nature, reject the whole transaction. 


e Where one field on an input transaction containing several or many fields 


has a minor error, it may be best to process the transaction and print or 
display an action message stating what needs to be corrected. 


On a rejected or error transaction, print the entire input transaction, just 
as it was entered, for the user to see. Indicate the position of each column 
or position of input. 


Write each error message as meaningfully as possible. Specify clearly 
what is wrong and why it was not accepted; or if it was accepted with an 
error, tell the user what is required to correct the error condition. The 
analyst should determine what a novice at the user’s job would need to 
know about inputting data and correcting errors. Be especially empathet- 
ic to human factors. Word the message for one who does not know the 
entire system. 


Think of every possible error and design the system to pick them up. 
Look for illogical input. That is, what would an untrained person or 
someone in a hurry do? Oftentimes, it is not the logical, but the illogical 
error that is the problem. 


Let the user know as soon as possible that an error has been made. If it 1s 
an interactive system, using a terminal, try to respond at the point of 
input. If the system is a daily batch type, try to make the error messages 
one of the first outputs. If the system is a monthly one, especially of a 
complex nature, it is sometimes advisable to run an input list and error 
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sheet, and then wait several days before the main programs are run. This, 
of course, permits a clean, up-to-date current month’s run rather than 
(always) having to wait for the following month to clean up the current 
month. 


Be certain to give an easily recognizable heading (title), with a date and 
DP job number, to the error list. Sometimes listing the user department 
and/or ultimate user on the form is helpful. 


In determining the seriousness of an error, the analyst must be familiar 
not only with the immediate use of the fields involved, but also with their 
ultimate use. The analyst, then, must know what other programs use the 
input data, when they access it, and what use they make of it. Sometimes 
a minor error in one system is a major one to another interfacing system. 


e It is also worthwhile to supplement the error messages themselves with 
appropriate material in a user manual. This is especially helpful for 
training new people, or for handling rarely occurring messages. 


e One thing to recognize, and try to avoid, is allowing one system to accept 
data that it feeds to another system that later rejects it. Consistency, in all 
respects, should be the rule. “Rejection at the earliest possible time” 
should be considered a basic principle. 


Specifying Data Elements, Edits, Audits 


Figures 8 through 15 illustrate how the dictionary approach may be used to 
specify the data elements, the data edits and audits required, and the error 
messages needed for a claim ending a manufacturing process, the final claim 
transaction. 


In Figure 8, the analyst first provides a short background statement on the 
needs and advantages of a final claim in a manufacturing environment. 


Figure 9 provides a specific definition of the final claim transaction, the entry 
mode for the transaction, and the data elements required. 


FINAL CLAIM 


One of the prime advantages of the system is to collect final machine claim 
transactions from the manufacturing floor, utilize the data internally for 
order tracking and disposition notification, and then forward the required 
information to the plant master order system so the open order condition 
can be updated. 


The final claim module should be so structured as to allow input by a 
department that is different from the department that actually built the 
unit. 


Current plans call for the final test department to be separate from the 
department that is building the units. The Recon line, at this time, is 
apparently independent of the new production line. 


Figure 8. Example of a background statement concerning needs and advantages 


36 


FINAL CLAIM 


Definition: An input that indicates that a specific machine serial number 
(and therefore, generally, a plant order number) has com- 
pleted the manufacturing build cycle (including testing). 


Entry Mode: Final claims should be made primarily by a 3793 with a 
3277 as a backup or alternate input mode. 


Data Elements: The following data elements should be input manually: 
e Machine Serial Number 
e Control Field 


e Time Audit Override Code 


The system should automatically provide the following 
data elements when the input transaction is made: 


e Date of Final Claim 
e Time of Final Claim 


Note: For final claiming, it is expected that the machine 
type would be derived automatically by the 
system from a function key, terminal addressment, 
or an input code of some kind. Input of the full 
four position machine type field is the least 
preferable of all techniques. 


Figure 9. A specific definition of the final claim transaction 
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In Figure 10, the first element is defined in detail, showing specific edits 
needed. The system responses (messages) to those edits are shown in 
Figure 11. 


Figure 12 shows the data audits required, while Figure 13 shows the system 
responses (messages) required to report the results of those audits. 


The second element (control field) and the edits it requires is shown 1n Figure 
14, while Figure 15 explains the responses needed by those edits. 


Because these examples are primarily concerned with edits, audits, and error 
messages as related to data element definition, it is irrelevant as to whether 
they are received from an interactive system, on a display, on a keyboard 
printer, or from a batch system on an overnight, weekly, or monthly schedule. 
Further, it is left to the reader to address the obvious user questions of: What 
corrective action is necessary? How do I doit? When do I do it? 


DATA ELEMENT EDITS 
Field Abbreviation: ‘““MACSR”’ 


Field Name: Machine Serial Number 


Field Definition: ‘A number that identifies a machine within a product 
type.”” (Data Element Label is ‘“MACSR’” in the plant 
master order system.) 


Field Length: Seven positions 
Field Type: Alphameric 
Edits: The following edits will be in effect: 


1. No blanks permitted, entire field must be utilized. 


2. No special characters allowed (“,-, etc.), except ‘“$” in 
first position. 


Figure 10. Definition of the first element and system edits needed 


EDIT ERROR MESSAGES FOR MACHINE SERIAL NUMBER 


Error response for Edit 1 should contain the following: 


A. The exact user input reflecting the column number(s) in which 
the data was entered. 


A message such as the following should be displayed: 


“Input invalid, transaction rejected. Field not completely 
used -- blanks occur in input.” 


Error response for Edit 2 should contain the following: 


A. The exact user input reflecting the column number(s) in which the 
data was entered. 


A message such as the following should be displayed: 


“Input invalid, transaction rejected. Special characters used in 
alphameric field.” 


Specific Example for Edit 1: 

User inputs Serial Number ‘’2-78901” 
The system responds with: 
(A) ‘Serial Number ‘2-78901' input. 


(B) Transaction Rejected due to blanks in input field.” 


Specific Example for Edit 2: 
User inputs Serial Number ’‘24* -901’ 


The system responds with: 


(A) “Serial Number ‘24* -901‘ input. Transaction rejected due to 
special characters in alphameric field.” 


Figure 11. Example of system responses to the edits needed in Figure 10. These are the 
responses to the user inputting the element 


AUDITS FOR MACHINE SERIAL NUMBER 
The following audits should be in effect: 


The machine serial number must be stored in the data base. 


The machine (order) must be in an in-process status. 


The machine must have been in-process for X period of time. (X will 
be provided by a table that identifies, by machine type-model and 
production type, a reasonable time for final claiming to be made 
after first claim. This time will be input by manufacturing. ) 


Note: This field machine serial number is used in conjunction with the 
data element “‘control field’”’. 


Figure 12. Example of a statement of data audits required for inputted data 
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AUDIT ERROR MESSAGES FOR MACHINE SERIAL NUMBER 


Error response for Audit 1 should contain the following: 


A. The exact user input reflecting the column number(s) in which the 
data was entered. 
A message such as the following should be displayed: 


‘Transaction rejected, machine serial number not stored in the data base.’ 


Error response for Audit 2 should contain the following: 


A. The exact user input reflecting the column number(s) in which the data 


was entered. 
A message such as the following should be displayed: 


‘*Transaction rejected, machine serial not in an in-process.status. Status 
codes are ““XXXX”. (Place here the values of the four system status 
codes W, X, Y, and Z.) 


Error response for Audit 3 should contain the following: 


A. The exact user input reflecting the column number(s) in which the 
data was entered. 


A message such as the following should be displayed: 


‘"Transaction rejected, machine serial number input has not been in 
process long enough to be completed.” 


Figure 13. System responses required to report to a user the results of data audits 


DATA ELEMENT EDITS 
Field Abbreviation: N/A 
Field Name: Control Field 
Field Definition: The two low-order positions of the Plant Order 


Number (Data Element Label is ““PLORN” on the 
plant master order system.) 


Field Length: Two positions 


Field Type: Alphameric 


Edits: The following edits will be in effect: 
1. No blanks permitted, entire field must be used. 


2. No special characters allowed (*,-, etc.). 


Figure 14. The second data element and the edits it requires : 


, 


EDIT ERROR MESSAGES FOR CONTROL FIELD 


Error response for Edit 1 should contain the following: 


A. The exact user input reflecting the column number(s) in which the 
data was entered. 


A message such as the following should be displayed: 


“Input invalid, transaction rejected. Field not completely used 
-- blanks occur in input.” 


Error response for Edit 2 should contain the following: 


A. The exact user input reflecting the column number(s) in which the 
data was entered. 


A message such as the following should be displayed: 


‘Input invalid, transaction rejected. Special characters used in 
alphameric field.” 


AUDITS 


The following audit should be in effect: 


Once a match has been found by machine serial number, on the MALCS 
data base, a comparison should be made with the two low-order positions 
of the corresponding Plant Order Number on file and the ‘’’Control Field” 
input. (An exact match must be found prior to this input transaction 
being accepted.) 


Figure 15. System responses needed to report the result of the edits specified in Figure 14 
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Input Audit Listings 


Master File Listings 


Control Information 
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In some ways, principally due to their help in problem solving situations, 
input listings have been related to error identification listings. 


Provide a daily list of all manually input transactions, and a list of all input 
via card, tape, disk, or terminal from another system. The list should have 
specific program identification (for example, DP job name and number) and 
date. Users should keep these listings for a period of time, depending upon 
the run frequency, long term reference value, and storage availability. Al- 
though daily listings are generally the most bulky, saving these for at least six 
months to a year is not unusual for some types of programs. Retention 
problems may be resolved by the use of mass storage devices such as the IBM 
3850 Mass Storage System. Payroll and some accounting needs may differ 
drastically from many purchasing, production control, receiving, or manufac- 
turing needs. 


Input audit listings, especially for batch systems, have often been invaluable 
for problem solving. 


For reference purposes, analysis, or operation use, periodic printouts of 
master files are quite useful, especially for small files. For some new systems, 
this can be most beneficial. 


Control information, like input audit listings, is closely related to error 
messages. In fact, sometimes it is only through such things as record counts 
that some types of errors can be detected. 


There are a number of ways that control information can be used. Some 
relevant points in developing and using automated control information are: 


e Create a count of the number of output records written, by record type, on 
an interfacing file. (That is, on an output file from one system to be used 
as an input file in another system.) 


e Keep a count of all records, by record type, of all incoming transactions. 
This is usually most valuable when control counts exist from the system 
that originated the file, and for those input files that may not have their 
input listed. 


e Program a count of the number of records, both incoming and outgoing, 
on all master files that are updated by the system, for each program in the 
system. Match it, if possible, with counts of transactions that add and 
delete records to the file. 


A count should be taken of the number of each type of output form 
processed (printed) by the system. In addition, it is sometimes helpful to 
record totals or subtotals of various kinds within each type of major 
category (for example, the number of production and the number of 
nonproduction purchase orders printed). 


Reports 


Each control sheet should be properly headed, with job name, a DP 
number and date. 


Clearly and exactly label each total. Avoid colloquial or generic names: 
be specific (for example use “job”, not order, or “cancel” rather than 
alter, or “delete” rather than cancel if such be the case). 


Make certain that comparative or relational control totals are read as soon 
as possible to detect errors so that they may be corrected by the computer 
(reruns, etc.) as much as possible, rather than manually. (There are few 
things as exasperating as finding that the wrong file has been used, and 
everything must be re-created or backed out manually because the con- 
trols were not verified soon enough.) 


Another form of control, sometimes more closely linked to audits, is date 
control. Specifications are written so that compares are made to ensure 
that only the most current file is used, or that files created outside specific 
date ranges are flagged, or not read into the system (program). 


There are a number of items to be aware of when designing reports — whether 
they are to be printed or displayed on terminals. Among the things to consid- 
er, specify, or use are: 


Give each report a meaningful, clear title descriptive of its nature or use. 


Be certain to put a DP job number and date on the report, preferably at 
the top of each page. 


Sequentially number each page. If the report is broken into groups to be 
distributed to different people, make the page number consecutive within 
each group (rather than for the report as a whole). 


If the report, or sections of it, is confidential or for use only within the 
company, distinctly label each page accordingly. For example, “Jones 
Co. Confidential” or “For Jones Co. Internal Use Only”, etc. (It should 
be noted that proper classification also includes knowing when a report 
can be declassified. In some instances, the date or other conditions under 
which a form can be declassified are printed on the form.) 


Specify the frequency and time that the report is to be run. For example, 
daily, weekly, monthly, on request, by 8:00 a.m. each Tuesday, the second 
and fourth weeks of each month, five days after accounting close, the fifth 
workday of each month, etc. 

Specify the size of paper. 


Specify the number of copies, that 1s, single sheet, three part, etc. 


Specify the distribution of the report: include such things as department 
number, location, bin number, etc. 


Indicate requirements like machine collating and bursting, if necessary. 
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Get some basic idea of the size of the report, obtain some blank IBM 
printcharts (GX20-1818) and start from there. (Figure 16 in this section 
illustrates and further discusses the printchart.) 


Most IBM printers have 132 print positions. All of these may be used by 
the analyst in designing reports. (Note, chart position No. | is sometimes 
left blank by some programmers due to certain programming language 
statements. If this is the case, the printchart is laid out from positions 
2-133 rather than 1-132.) 


Lay out the individual field headings, just as they should be when the 
report is run, always striving for clarity. The key question is: “Can 
someone who is somewhat familiar with the area read and utilize the 
report without being confused?” Appropriate abbreviations may be used 
when the terms are generally known and/or to conserve print space. If 
the abbreviations used are not those generally known, make certain that 
the users have a reference document that fully defines them or that a 
legend or glossary appears on the report. 


Field headings many times can be most effectively written using two lines 
rather than one. 
For example, 


Buyer E.C. Unit 
Num. No. Price 


Under each field heading mark each space in which printing will be done. 
Traditionally, an “X” is placed in each utilized field position. 


Leave several lines between the page or report headings and the individu- 
al field headings. | 


Skip one or two lines between groups or after each group and before and 
after totals. This is especially helpful where long lists are involved and/or 
the printing is eight rather than six lines to the inch. Readability is an 
important factor to consider in report design. 


For reports that are used at various locations, be sensitive to local needs, 
usage, jargon, slang, etc. Try to make the report more standard or 
universal. 


Often, in report design, the same data will appear on several reports but in 
different sequences. It is wise in such cases to devise totals that can be 
compared from report to report so that if any discrepancies occur, they 
may be detected early. | 


Bring the users in on report design, asking the question: “What do you 
need?” 
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Figure 16. Section A. 


This figure shows how an IBM print chart (GX20-1818) — mentioned earlier under Output — Detail Level Forms and in 
this section — is used to lay out a form. Virtually all computer-prepared reports and forms can be designed using this 
chart. In Section A the analyst has designed the form and used X’s to represent maximum field size. Because some 
individuals have difficulty visualizing a form/report without actual data, in Section B the analyst has used letters and 
numbers to show the data. Section C shows an actual report as prepared on the computer 
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Figure 16. Section B. 


DATE 11/23/7X 


ORDER 
NUMBER 


**BZM INC 
96-B3498-671-2 
96-B3498-671-Z 
96-A3097-766-K 

**BZM INC 
96-V321L1-766-M 02 
96-V321L1-766-M 03 
#*HARRIS MACHINERY DIV 
96-V3361-773-M 16 
#*KOLAN INCORPORATED 
96-V3087-559-K OO 
**KOLAN INCORPORATED 
96-V3149-E80-G O12 
96-V3149-E80-G 02 
**KOLAN INCORPORATED 
76-W3839-568-S 00 
76-W3839-568-S 01 
**CENTRAL MOTOR EXPRESS 
87-B3396-575-M OL 
*xCITY OF DENNIS 


03-V3024-569-M OL 


03-V3027-662-L o1 


Figure 16. Section C. 
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ScD DATLY EXPEDITGOR REPORT 


DESCRIPTION EXPEDITOR 
COMMENTS 


#692665 
ELECTRONIC JABR BADGES 110379 120679 
ELECTRONIC JABR BADGES 1410379 120679 
BK9440710S CASH ELECTRON 072279 101079 081579 


CHICAGO #6926655 


SUPPLY 100 BADGE INSERTS 022479 051079 121279 CRO9T60779 


VENDOR TO RECODE CARD KEY 022479 121279 CRO9T60779 


ENDICOTT #7538116 


GASKET-OUT #K5-1006 031479 032879 033179 


JACKSON #7459866 


RENEW MONTHLY SERVICE 010579 123179 EXPIRES/MO 
#777849 
SERVICE FOR COPIER, 080879 081979 


BOXES 200 SHEETS (BOX) 080879 081979 


KANSAS CITY #2778490 


INSTALLATION UNITS PER MO 022279 011779 EXPIRES/MO 
MONTHLY MINIMUM ON RENTAL 022279 011779 EXPIRES/MO 
#753917 


ZELAG MOTOR MODEL Z31L 110379 111579 


DENNIS #9458720 


ADD WATER SERVICE 121779 123179 EXPIRES/MO 


FOR ANALYSIS PURPOSES 122179 123179 EXPIRES/MO 


e In report analysis the analyst should not only ask what the users need, but 


also what an analyst needs or may need to solve problems once the system 
is installed and operating. For example, when something happens, can it 
be traced? Some reports or some parts of some reports are designed 
mostly or solely for error identification and correction. Although such 
topics as error identification and input lists, etc., are discussed separately, 
it is also a good reminder in general report design to ask what is needed 
from this respect also. 


Calculate totals for each group or subgroup in a report, as well as “final” 
or overall totals. 


Adequate provisions must be made for spacing between fields. Generally 
speaking, one or two positions is satisfactory. 


The use of special characters, symbols, or codes can often be of help in 
saving space, easily highlighting certain situations, etc. For instance, an 
asterisk (*) might designate certain problems or exceptions, and instead of 
trying to print a lot of complicated messages on each line, requiring 
significant space, the analyst can create a one to three position field 
containing various codes, the meanings of which would be printed (as a 
legend) at the end of each group or subgroup to whom report distribution 
is made (buyer, analyzer, account, etc.). 


For reports that are shared by one or more divisions of a company or 
from company to company, be certain to specify the originating location 
on the report. Also, double-check for confidential or internal use only 
data before outside distribution is made. 


Many people cannot get a good understanding of a report by looking at a 
printchart or display design with marks on it. It is often very helpful to 
show a generalized printchart (with x’s on it) and to follow it up with an 
example of how the report or display would look, using dummy content in 
the fields and for totals (Figure 16). 


When designing reports that will appear on visual displays, the analyst 
must be familiar with the equipment — screen sizes, number of characters 
to a line, number of lines to the screen, contrast, screen usage restrictions 
due to software/hardware limitations, location of terminals, sign-on and 
sign-off abilities, security restrictions and provisions, response time limita- 
tions or restrictions, etc. 


In addition, special attention to human factor considerations should be 
given when designing input and output screens for visual displays. Areas 
such as element-by-element, line-by-line, or full screen processing must be 
looked at from hardware/software capabilities, and the needs of the 
specific jobs involved. Also, the clarity of heading data is very important, 
particularly if the operator must use a number of different displays and 1s 
likely to be interrupted by the telephone, other employees, or manage- 
ment. Examples of screen design are shown in Figure 17. 


On the technical side, the analyst should verify that the data from which 
the report will be generated will be available. Subtleties may exist in 
ensuring that weekly, monthly, or quarterly reports have the necessary 
information. Daily, weekly, or monthly temporary files must be created 
to hold data for a period of time, in some cases. 


Like forms design, there are many considerations to good report design, 
most of which will come out by working with and designing a number of 
reports. Asking an experienced analyst to critique a newly designed form 
or display can often help tremendously. 


Additional heip or ideas can often be derived from reviewing and ana- 
lyzing a number of different reports and displays designed for different 
areas, needs, and times. The analyst should not adhere only to those 
related to the analyst’s specific area. Often, too, System Reference Librar- 
ies, application briefs, write-ups, and books give good supplementary 
ideas. 
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Section B. 


Figure 17. Section A is an example of a design specification for a visual display. The headings are what the analyst is requesting, 
X’s indicate maximum field size. Section B shows the same display layout with values placed in the various fields to 
help the users better understand what it is they will receive. It is also an aid to the programmer in developing 
programming specifications for the display. For a complete specification package, the analyst would also indicate 
why this output display is necessary; when and how it is to be obtained by the user; edits, audits, and error messages 
needed to properly process the input request; and each element (field heading) would be defined in the Data Element 


Dictionary 
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Updating Master Files 


Processing - Detail 


One of the most common needs of a system is updating the master files. This 
is generally done via manual transactions (cards, terminal, etc.) directly into a 
system (program), or by interfacing mediums such as cards, tapes, disks, 
diskettes, or telecommunications from one system to another. 


The analyst specifies the files to be updated, their frequency, the proper edits 
and audits, and detail security techniques. In some cases, it is necessary to 
install an individual as data manager or data base coordinator to monitor the 
integrity of the system and the data entering it, and to also create and assign 
security codes and levels of security. 


Normally, an analyst is involved with the type of processing and not how the 
processing is accomplished. (Unless program specifications are being provid- 
ed, systems engineers or systems analysts usually do not need to get into that 

level of detail.) 


A useful technique is to create a dictionary of each field heading and then 
specifically define each term used. The following section is an example of a 
form used for such purposes. Each heading term should appear on a separate 
sheet. 


Although processing is usually considered to be the third aspect in the funda- 
mentals of designing a system, it is really closely linked to the output if one 
uses the dictionary approach. In giving the report or display requirements, 
fields must be at least generally defined (abbreviation, name, size, etc.) and it 
is only a few steps further that the processing requirements and definitions 
for the various fields can be done. These same principles also apply, in many 
ways, to input specifications. 


It is highly recommended then, for anything but the simplest of systems, to 
use the dictionary approach. 


Form Heading Dictionary Example 


Field Abbreviation: (The exact abbreviation or heading as it appears on a 
report, display or form.) Examples: Bu.; Qty. Ord.; Ord. No.; P.O. 


Field Name: The full name of the field. Examples: Buyer, Quantity 
Ordered, Plant Order Number, Purchase Order (these refer to the above 
abbreviations) 


Brief Description/ Meaning/ Derivation: The specific definition of a unique 
field: What it is, from where it is obtained, how it is obtained and/or used. 
Mathematical formulas, spec definitions, and derivation techniques are all 
applicable here. Examples: The buyer placing the order, from File X, Field 
Y. (This might distinguish this field from the buyer assigned to a part num- 
ber.) The quantity ordered for a specific job number, from File W, Field Z. 
(This might distinguish this field from the total quantity on order for a part or 
the total quantity ordered on a P.O. for all jobs on a P.O.) 
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Update Frequency: (How often, or when is a field updated.) 
e As each purchase order is placed. Once only. 
e As each job on a purchase order is placed. Once only. 
Field Length: (The number of positions the field will occupy.) 
Examples: Two positions; seven positions 


Field Type. (Alphabetic; numeric, alphameric with no special characters 
allowed.) 


Examples: Alphameric; numeric 


Default Values/ Rules: Specific rules should be given here to tell what should 
occur if the field is not found or left blank. For example, a blank in an input 
field designating originator might always default to “01”; or in defining a 
sequence, might always be considered one way (ascending); or the date might 
default to the current date; or the location code, if not input, would default to 
a specified value; etc. 


NOTE: It is sometimes useful to designate whether a field is output or input. 
Fields should also be designated as system-created, when appropriate. For 
example, the system might “create” or automatically load the current date 
and/or time when certain transactions are input. The analyst might specify 
“MM DD YY” (month, day, year); update frequency as being whenever trans- 
action “ABC” 1s input, etc. 


Utilizing the Dictionary Approach 
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This section attempts to clarify some of the ways the dictionary approach can 
be utilized to define various data elements. All examples, Figures 18 through 
24, illustrate data elements that were defined for an actual system. 


The reader is encouraged to pay special attention to the titles, arrangement of 
fields, and the various types of information that can be defined using the 
same headings. Several different types of data elements are illustrated to 
show how various conditions may be defined. 


One analyst who normally uses this approach has prepared a pretyped master 
sheet for personal use. Whenever additional sheets are needed, a copying 
machine is used to reproduce the quantity needed. 


There are, of course, other approaches available for obtaining “blank” sheets 
available for analysts to use. If anticipated usage is high enough to justify it, 
one approach is to have an in-house art department design a master for the 
form. Then, the master can be used by an in-house reproductions depart- 
ment or an outside printer to prepare the necessary quantity. In some in- 
stances, it may also be desirable to have the preprinted forms padded 25 or 50 
sheets to a pad. 


Field Abbreviation: REL QTY 
Field Name: New Order Release Quantity 
Brief Description/Meaning/Derivation: 


A four-position numeric field indicating the number of orders to be applied 
against a particular line item input. 


Update Frequency: N/A (not applicable) 

Field Length: Four positions 

Field Type: Numeric 

Default Values/Rules: Blank = Defaults to 1 (one) 


Field Use: Input 


Figure 18. This is an example of the definition of a relatively simple numeric data element 
having an implied default value 


Field Abbreviation: BGN STB 


Field Name: Beginning Start-To-Build Date 


Brief Description/Meaning/Derivation: 


A four-position date indicating the Start- To-Build day for which unreleased 
orders are to be selected for release. If release is to be confined to a specific 
range of dates, this date is the first in the range. 


This date is the user input field that is equivalent to (that is, matched against) 
the Data Element Field Label ’*SCHSB” from the plant master order system. 


Update Frequency: N/A (not applicable) 
Field Length: Four positions 
Field Type: Numeric (month, day; MMDD) 


Default Values/Rules: Blank: The system goes back to the oldest day for 
which any unreleased order exists on the data base. 


Field Use: Input 


Figure 19. An example of the definition of a data element having a default rule. The 
element is also used in combination with another data element to show a range of 
values (See element “END STB” Figure 20) 
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Field Abbreviation: END STB 
Field Name: Ending Start-To-Build Date 
Brief Description/Meaning/Derivation: 


A four-position date indicating the last day in a range of Start-To-Build 
days for which orders are to be selected for release. 


Update Frequency: N/A 


Field Length: Four positions 


Field Type: Numeric (month, day: MMDD) 


Default Values/Rules: None 


If blank, not used. i.e., no range of dates used, if 
no input in this field. 


Field Use: Input 


Figure 20. An example of the definition of a data element that is the second element in a 
range of values (see ““BGN STB’’, Figure 19) 


Field Abbreviation: 1D CD 


Field Name: (Field) Identification Code 


Brief Description/Meaning/Derivation: 


This code identifies (or designates) which type of data is input in the next 
field, which is multifunction in nature. 


Field Length: One position 
Field Type: Alphabetic 
Field Values: C = Customer number 
O Order number 
S Machine serial number 


Default Values/Rules: None 


Field Use: Input 


Figure 21. This example shows the definition of a data element that has specific field 
values and is used to qualify another data element (see “CUST/ORD/SERIAL”, 
Figure 22) 


Field Abbreviation: CUST/ORD/SERIAL 


Field Name: Customer Number (or) Order Number (or) Machine 
Serial Number. 


Brief Description/Meaning/Use/Derivation: 


This field contains the customer number, order number, or machine serial 
number that is being input to the system. (To be released, blocked, un- 
blocked, etc.). 


Field Length: © Seven numeric positions for customer number (or the 
first five for a generic customer number). 
e Six alphameric positions for order number. 
e Seven numeric positions for machine serial number. 
Field Type: Alphameric 
Default Values/Rules: None 


Field Use: Input 


Figure 22. This is an example of the definition of a multi-purpose data element whose 
meaning is determined by the input in another (preceding) field (see ““ID CD”’, 
Figure 21) 


Field Abbreviation: N/A (not applicable) 
Field Name: Date Of Final Claim 
Brief Description/Meaning/Derivation: 


This field is created on the master file by the system when a final operation 
claim occurs. It shows the month, day, and year that the input was made. 


NOTE: If for some reason the input is made on a day after the final claim 
is made, provision should be made to show the date the machine 
was actually completed (as opposed to the date the input was 
made). For further details, see final claim specifications, 
‘‘Exception Processing” section. 


Update Frequency: Once only, at the time of final claim. 


Field Length: Six positions 


Field Type: Numeric (month, day, year; MMDDYY) 


Field Use: Output, see appropriate inquiry displays. 


Figure 23. This example illustrates the definition of a data element that is generated by 
the system 


Field Abbreviation: UNREL ORDERS 

Field Name: Unreleased Orders 

Brief Description/Meaning/Derivation: 

The number of unreleased orders on the data base (for a particular machine 


type/model/day, etc., depending upon the report). The system calculates 
this field each time the display using this field is requested. 


Update Frequency: As releases occur throughout the day 
Field Length: Four positions 
Field Type: Numeric 


Field Use: Output 


Figure 24, This example shows the definition of an output data element that is calculated 
by the system whenever a user requests it 


Equipment Space-User Area 


User Education 
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In assessing total user needs, adequate provision should be made to ensure 
that proper space is allocated for any equipment to be placed in the user area. 
In some instances it may be wise to consult with internal or external experts 
for guidance. In the industrial sector the facility’s industrial engineering 
department can usually be of assistance, while in other sectors the group may 
be called office planning, interior design, etc. External groups that can 
usually provide guidance include the local telephone company, electric 
utility, etc. 


The analyst should be concerned with what equipment (and to some extent, 
supplies) is needed, and where it is to be placed. Such things as displays, 
printers, modems, telephones, line printers, control units, cables, etc., as well 
as proper workstation space furniture, electrical outlets, and storage room 
should be addressed and provided for. Consideration should also be given to 
the environmental factors with respect to equipment placement: noise, heat, 
humidity, location, etc. 


Although user education is a separate phase from the analysis and design 
portions of an analyst’s job, some of the main areas are addressed in this 
section. 


Oftentimes, a quick review of the things necessary for education will high- 
light a point or two that might have been overlooked in the design phase, 
especially from the human factors viewpoint. Lack of problem solving or 
troubleshooting aids available for the system may become apparent. 


Deficiencies, inconsistencies, implied double meanings, and so on seem to 
surface in message wording, sort sequences, input lists, secondary fallback 
and recovery needs, procedural responsibilities, forms clarity, etc. Many 
things seem to be magnified when preparing for education classes. 


User education should include instruction concerning: 
e Inquiry transactions. How to input, when to input, where to input 


e Processing transactions. How, when, and where to input, their effect(s) 
and verification techniques 


e Error messages and corrective methods. What comes out, when and 
where 


Report distribution. Who gets what 


e Report requests. How to obtain reports 


Report reading. Meaning and use of a report 
e Storage and filing. What to keep, how long, why 
Proper filing sequence 


e Forms use. Which forms exist, for what purposes, who utilizes them 


Distribution. Before and after input and/or use 


Fallback and recovery techniques. What to do, when to do it, whom to 
see 


Procedural references. Corporate, plant, department, etc. 


Contact/support personnel. Whom to see for various problems, needs, 
etc. Name, department, location of analyst, programming, data process- 
ing, field engineering, reproductions, phone service, forms, and other 
interfacing or support areas 


¢ Vital records. Training should include a discussion of the vital records 
program, identification of files, retention cycles, storage and retrieval 
times, etc. 


e Security. The importance of physical and logical, general company and 
local requirements, special considerations, audits, etc. 


e Equipment usage. Training in the use of equipment — operational 
(specifically to a job) and technical (general use of equipment) 


aye) 


Vital Records 
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No manual of this kind would be complete without some mention of vital 
records. It is necessary, in normal systems design, to provide adequate 
fallback and recovery techniques for equipment as well as program failure. 
In addition, a formal disaster plan should be in effect, especially from a file 
preservation viewpoint, for major catastrophies. 


Specific files — usually master files — should be identified as critical to the 
running of the system, and a formal program initiated to routinely preserve 
these files, offsite if at all possible. A definite schedule for transporting each 
file to the secured area should be established, adhered to, and monitored. 
The schedule for shipment and preservation should be dependent upon the 
criticality of the file, its update frequency, the number of transactions updat- 
ing the file, the ability to regenerate the file, its company security sensitivity, 
security change frequency, and the like. 


Examples of files to which this applies include master name and address files 
(supplier, customer, employee, etc); master parts inventory files; master 
purchasing files (parts, quotations, consignment, open order, etc.); master 
receiving files (parts inventory, MRO, etc.); accounts payable; accounts 
receivable; personnel; etc. 


The idea behind a vital records program is to be able to restart the business in 
case of a fire, tornado, explosion, plane crash, flood, other disaster, with a 
minimum of effort in a more or less reasonable time. 


Each company should have its own internal vital records program. The 
analyst, in conjunction with the programmer and users, should determine 
which files should be sent to vital records storage, and the 
transmission/distribution frequency. It should be up to the data processing 
organization to operate and maintain the programs. Some organizations 
require routine user/analyst/programmer reviews of the vital records pro- 
gram, including current files and maintenance schedules. 


Functions of a Systems Analyst 


This section includes a short review of the more important functions an 
analyst performs in maintaining or designing a system and a few notes about 
each for ease of reference. 
File Initialization 
e Which files to be initialized 
e Where the data (fields) to be initialized is to come from (which files) 
e Which data elements to include, to extract 
e Cleanup techniques 
e Error identification and correction techniques 
e Statistics, control, and verification methods 
e Timing 
Interfacing 


e Which systems, files, procedures, department involved 


¢ What data (fields, elements, records, files) is needed; how to obtain the 
data 


e Standard error identification and correction techniques 

e Control statistics and verification techniques 

e Run frequency, timing 

e General job stream — defining dependencies 
Forms/Cards 

e Relation to current: by use and data element 

e Responsibility 

e “Testing” 

e Relation to operating procedures 

e Ordering/Number assignment 


e Design/Redesign/Modification 


57 


Operating Procedures 
e New 
e Revisions 
e Distribution 
e Local, Corporate, Functional and/or Departmental 
User Manual 
° Preparation of Material 
e Teaching 
e Review Sessions 
Special or Unique Selection, Exclusion Control, or Compare Logic 
e Identification 


e Use, non-use, or replacement, e.g., department codes, analyzer codes, 
account numbers, product codes, commodity codes, etc. 


Edits, Audits, Statistics 
e Relation to current 
e Clarity of information 
e Responsibility 
e Changes 
Tables 
e Identification of required vs optional 
e Initialization 
e Updating: method and frequency 
e Field sizes 
e Length 
e Relation to current 
e Responsibility 


e Relation to procedures 
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Formulas, Variables, Parameters, ‘Plug Factors’ 
e Identification of Required/Default/Optional 
e Initialization 
e Updating: method and frequency 
e Relation to current 
e Responsibility 
¢ Relation to procedures 
e Modifications, if any 
Reports 
e Relation to current, by use and data element 
e Contrast of content: advantages vs disadvantages 
e Frequency 
e Distribution 
e Responsibility 
e Relation to procedures 
e Modifications, if any 
Testing 
e Unit (module) testing 
e Systems testing 
e User acceptance testing 
e Parallel runs 
e Test data preparation 


e Assurance of proper work area, storage areas, supplies, security 
provisions, etc. 


User Hardware 
e Determination of 
e Ordering 
¢ Installation coordination 


e Education 
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Transferring Systems 
For expediency’s sake, programs and whole systems are sometimes picked up 
from other locations, rather than developing them locally. Evaluating an 
existing system, subsystem, or program requires an intimate knowledge of the 
current, local needs as well as an understanding of the system under 
consideration. 7 
The evaluation points are the same as the needs, goals, and objectives for a 
new system. The criteria against which they are measured are, in effect, the 
specs for the new system. 
It is wise to draw up a list of questions to address when appraising a system. 
Start with what it does and does not do; proceed to what the specifics (input 
and output) indicate; next, how the processing is accomplished; and then go 
to the interfacing and selection criteria and techniques. 


An evaluation is made by both programmer-analysts and systems application 
analysts to ensure that all aspects are considered. 


In picking up another system, or bringing material back to one’s own location 
to evaluate against, a checklist is often useful. The major items to include in 
such a checklist are shown under “Systems Review/Installation Package”. 
Systems Review/ Installation Package 
e User manual 
e Operating procedures 
e Manufacturers’ equipment and installation manuals, operator guides, 
installation and physical planning manuals, configurators, forms design 
reference guides, component description manuals, introduction to system 


books, message manuals, etc. 


e Examples of all printed/punched output — forms, reports, cards, etc. 
Blank and used 


e Examples of all input documents 

e List of all programs used — name, number, and language 
e Source decks 

e Special local macros used 

e Program listings 

e Test decks-programs, test data 

e Test results 

e Operating system used (requirements) 


e Program write-ups 
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e Program flowcharts 

e System flowcharts 

¢ Operational flowcharts 

e Data entry/keypunch instructions 


¢ DP procedures and write-ups — computer room (setup sheets), bursting, 
decollating, distribution instructions, etc. 


e List, location, and sample (format) of tables, special algorithms, constants, 
etc., used and the means to initialize and update them 


e List of all department numbers, bin numbers, account codes, account 
numbers, buyer, analyzer, routing, location, terms, distribution, codes, 
etc., that are used by the system and to what they refer 


e Disk, diskette, tape, card files used (name, number) and their formats 
e Sorts used — type used, fields, setup instructions, etc. 

e List of equipment used, run schedules, data flow, job stream 

e Special (local) utilities used, including GIS, APL, Select/360, RPG, etc. 


¢ Telecommunications needs — lines, modems, speeds, location, times, 
restraints, etc. 


e Identification of any supporting software used for communications 
purposes, such as TSO, CMS, DATATEXT/360, etc. 


e Names, mailing addresses, phone numbers of analysts, programmers, 
education specialists, and key users to contact 


Systems Analyst’s Responsibilities 


A summary of the responsibilities of a user systems analyst was expressed by 
Mr. A. B. Case, and is being included to give another perspective. 


Responsibilities of a systems analyst assigned to a user organization. 


I. Understanding the User 
A good knowledge of the user’s organization, procedures, and practices 
with emphasis on human interface with data handling systems — both 
input and output. 


II. Problem Definition 
Regardless of the source, a thorough understanding of the problem as 
the user sees it. 


Ill. Problem Analysis 
Independent analysis of the problem, its causes and resultant effects. 
Thorough examination of all aspects, like: frequency of events, human 
constraints, machine or program limitations, output required, etc. Must 
be able to separate “need” from “nice to have” aspects of problem. 
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IV Alternatives Examination 
Evaluation of the various solution alternatives available, including 
consideration of the time and manpower required and/or available to 
implement. 


V.Solution Selection 
Selection and presentation of a recommended solution to be 
implemented. 


VI. Specification Generation 
Detailed analysis of inputs, edits, algorithms, file organization, frequency 
of operations, and outputs. External interfaces, 1.e., other systems, must 
be considered. “What if” exercising is important. Detailed understand- 
ing of existing methods and manual procedures, if any. Complete, 
concise, timely documentation. 


VII.Jmplementation Plan 
Time and effort estimates to code, test, and install a working system. 
Milestone checkpoints included. 


VIII. Tracking 
Tracking and reporting on actual vs plan, both own and support 
organization’s effort. 


[X.Jnstallation 
Test results review, user manuals, key user training, support user genera- 
tion of procedures, management presentations. 


X. Utilization M onitoring 
Ongoing review of system utilization. Effectiveness, efficiency, measure- 
ments of system usage, and identification of deficiencies and/or en- 
hancement needs. 


Glossary 


Cutover. This ts usually defined as that point in time when the 
official or formal operating change is made from the old way of 
doing business to the new system. 


Document of Understanding (DOU): A document that defines the 
responsibilities of the various areas involved in designing, install- 
ing, and using a system. 


DOU: See “Document of Understanding”. 


File Cleanup: This generally refers to a purification process of the 
current records and/or files so that the new system will be started 
with good, clean records. The better the condition of the records 

used by the new system, the better the initialization and easier the 
programming. 


Installation. The completion of the activities involved with de- 
signing and developing a system, and the actual utilization of the 
new system on a regular, production schedule. 


Parallel Runs: Production type runs of a new system that are 
made while the former system is still running. Usually, detail 
comparison of output between the two systems is made to ensure 
that the new system operates as expected. 


Pilot Run: The first production run of a new system, using live 
data. In the case of major modifications or enhancements, the 
first production run with new programming installed. The ana- 
lysts and programmers are usually present, and do all they can to 
assist the users, clear up problems, and ensure data integrity. 


Systems Reference Library (SRL): The name IBM uses to desig- 
nate technical reference manuals. 


SRL: See “Systems Reference Library”. 
Test Plan. A document that defines what is to be tested and by 


whom. Sometimes it includes such things as dates of testing, 
equipment to be used, how used. 
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Selected IBM Publications, Forms, and Tools Useful in Systems Analysis 
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Form Number 


GE20-0527 


GF20-8 102 
GC20-8152 
GC20-8078 
GA24-3488 
GC20-1851 
GE20-8067 
GF 20-6088 
GF20-0074 


SF20-8150 
SF20-8135 


GX28- 1630 
GX20-8020 
GX20-8021 
GX20-1971 
GX20-1970 
GX20-1818 


GX20-1702 


GF20-8 172 


G320-1621 


SR20-4441 
GC20-1699 
GR29-0280 


GR29-0281 


GH20-1511 
GH20-1510 
GH20-1464 
G320-1974 
through 
G320-1981 
GC20-1670 
GE20-0541 


Description 


Business Systems Planning, 
Information Systems Planning 

Guide 

Decision Tables — A Systems 

Analysis & Doc. Technique 
Flowcharting Techniques 

Form & Card Design 

Form Design Reference Guide 

for Printers 

HIPO — A Design Aid & 
Documentation Technique 

PERT — A Dynamic Project 

Control Method 

Planning for an 

IBM DP System 

An introduction to IBM 

Punched Card DP 

Basic System Study Guide 

Study Organization Plan: 

The Approach 

Decision Table Worksheet 
Flowcharting Template 

Flowcharting Worksheet 

HIPO Template 

HIPO Worksheet 

150/10/8 Printer 

Worksheet 

Proportional Record 

Layout Form 

Installation Management 
Bibliography 

Marketing Publications 

KWIc Index 

IBM 3270 Screen Design 

Data Processing Glossary 

Computing System 

Fundamentals: Overview 

Computing System 

Fundamentals: Techniques 

A COPICS Execution System — Implementation Guide 
A COPICS Execution System — Application Design Guide 
A COPICS Execution System — User’s Guide 
Communications Oriented Production 
Information and Control System 
(Eight Volumes) 

Data Processing Techniques 
Manufacturing Applications and the 3790 
Communication System 


GE20-0593-0 
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